home *** CD-ROM | disk | FTP | other *** search
/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-20 / tcp90134.zip / TCP90134.TXT < prev   
Text File  |  1990-09-14  |  9KB  |  237 lines
  1. Path: tosspot!indep1!pete
  2. From: pete@indep1.UUCP (Peter Franks)
  3. Newsgroups: to.tosspot
  4. Subject: TCP Digest #134
  5. Message-ID: <1335@indep1.UUCP>
  6. Date: 14 Sep 90 01:24:28 GMT
  7. Reply-To: pete@indep1.MCS.COM (Peter Franks)
  8. Followup-To: to.tosspot
  9. Distribution: to
  10. Organization: as little as possible
  11. Lines: 224
  12.  
  13. TCP-Group Digest            Mon, 10 Sep 90       Volume 90 : Issue 134
  14.  
  15. Today's Topics:
  16.                       Choosing an SSID (4 msgs)
  17.                               Mailbox ID
  18.                             RSPF problems
  19.                              rspf status.
  20.                  RSPF version doesn't do ARP replies
  21.  
  22. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>
  23. Send requests of an administrative nature (addition to, deletion from the
  24. distribution list, et al) to: <ListServ@UCSD.Edu>
  25.  
  26. Archives of past issues of the TCP-Group Digest are available
  27. (by FTP only) from UCSD.Edu in directory "mailarchives".
  28. ----------------------------------------------------------------------
  29.  
  30. Date: Sun, 9 Sep 90 08:47:22 -0700
  31. From: brian (Brian Kantor)
  32. Subject: Choosing an SSID
  33. To: packet-radio, tcp-group
  34.  
  35. Originally the AX.25 SSID (secondary station identifier) was more or
  36. less intended for those who had multiple stations to be able to
  37. differentiate between them even though they had the same callsign.
  38. Thus WB6CYT-1 and WB6CYT-0.
  39.  
  40. However, they're immensely useful in selecting the FUNCTION that a
  41. particular connection provides.  For example, -0 is a person, -1 is a
  42. digipeater, -2 is a BBS, -3 is TCP/IP, etc.  Whether these are just
  43. logical separations or whether it is actually utilising different
  44. equipment is usually moot from the standpoint of the person connecting.
  45.  
  46. Of course, with net/rom complementing the SSID every time it
  47. masquerades as a connecting user, such distinctions may well make no
  48. difference.  But in more enlightened areas where net/rom does not hold
  49. sway, the differing SSIDs could be useful.
  50.  
  51. The examples above are somewhat common in my area, but not universal.
  52.  
  53. Is there any sort of consensus as to which SSID should be used for what?
  54.     - Brian
  55.  
  56. ------------------------------
  57.  
  58. Date: Sun, 9 Sep 90 14:40:29 CDT
  59. From: brainiac!jrc (Jeffrey Comstock)
  60. Subject: Choosing an SSID
  61. To: shamash!ucsd.edu!tcp-group@umn-cs.cs.umn.edu
  62.  
  63. Here is what is going on in the Minnesota area:
  64.  
  65. -0  Mixture of RLI bbs's, Keyboard to Keyboard, Personnal 
  66.     mailboxes on Kantronics and AEA TNC's.
  67. -1  Keyboard to Keyboard.
  68. -3  Msys BBS's.
  69. -9  Netrom and TCP/IP.
  70. -15 The first hop from a netrom.
  71.  
  72. The -9 for TCP/IP and Netrom is because initially most connects
  73. to the TCP/IP stations were via Netrom connections.
  74.  
  75. It seems that -7 is the international designation for KA-Nodes.
  76.  
  77. Jeff
  78.  
  79. ------------------------------
  80.  
  81. Date: Sun, 9 Sep 90 23:31:43 EDT
  82. From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
  83. Subject: Choosing an SSID
  84. To: brian@ucsd.edu, packet-radio@ucsd.edu, tcp-group@ucsd.edu
  85.  
  86. For whatever reason we in the Mid Atlantic area are (generally) using
  87. -8 as TCP/IP SSID with IPxxx as netrom ID - I.E. wa3dsp - IPDSP
  88.  
  89. Doug
  90.  
  91. ------------------------------
  92.  
  93. Date: Mon, 10 Sep 90 10:10:18 BST
  94. From: Dave Lockwood <vision!davel@relay.EU.net>
  95. Subject: Choosing an SSID
  96. To: tcp-group@ucsd.edu
  97.  
  98. Here in the UK, the use of SSIDs is sorta "standardised". But like most
  99. standards, we have quite a few of 'em :-).
  100.  
  101. Our Net/Rom Nodes and BBSs require special licenses from our DTI (=FCC).
  102. Net/Roms are GB7+two letters and BBSs are GB7+3.
  103.  
  104. In this group, the "standard" is:
  105.  
  106.     -0    No recommendation
  107.     -1    Microwave
  108.     -2    144 MHz
  109.     -3    HF
  110.     -4    70MHz (4 metre band)
  111.     -5    TCP/IP
  112.     -6    50MHz
  113.     -7    432MHz
  114.  
  115. The rest are also "no recommendation". As here such stations proliferate to
  116. a ridiculous degree (my home town of Wakefield pop 75000) has three BBSs
  117. serving it, all providing exactly the same functionality), users get used
  118. to seeing the SSIDs used as above and tend to adopt the same principle.
  119. There's certainly no legal reinforcement of the above, indeed it's interesting
  120. to note that the licensing authority views the callsigns embedded in the
  121. address field of AX.25 frames as irrelevant and are not judged to be
  122. "identification". Callsigns in plain text (in the info field) are.
  123.  
  124. Returning to SSIDs, when I allocate an Amprnet address, the text I send
  125. to the requestor includes a sentence: "When operating your TCP/IP station
  126. the recommended callsign/SSID is 'G9XYZ-5'". The majority of users
  127. comply, but I've noticed the ones who don't tend to be TCP/IP gurus.
  128. Is there a lesson here (lotsa :-) before the flames start).
  129.  
  130. 73
  131. -- 
  132. -------------------- I'm totally incommunicado, except for ---------------------
  133. Dave Lockwood            ...!uunet!mcsun!ukc!vision!davel      davel@vision.uucp
  134. Technical Consultant    ...!uunet!bulus3!bungia!vware!davel   davel@vware.MN.ORG
  135. VisionWare Ltd,               G4CLI@GB7YHF.194.GBR.EU        dave@g4cli.ampr.org
  136. 57 Cardigan Lane,                  D.LOCKWOOD@ICLX            davel@vision.co.uk
  137. Leeds, LS4 2LE,                     +44-532-788858                +44-831-494088
  138. United Kingdom                      +44-532-304676                   "Hey, You!"
  139. ----------------------- VISIONWARE DOS/UNIX INTEGRATION ------------------------
  140.  
  141. ------------------------------
  142.  
  143. Date: Sun, 9 Sep 90 23:34:32 EDT
  144. From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
  145. Subject: Mailbox ID
  146. To: tcp-group@ucsd.edu
  147.  
  148. A local BBS operator has requested that the NOS BBS ID be changed
  149. from [NET-$] to [NET-H$] - this was done in net towards the end but
  150. somehow got lost in NOS.
  151.  
  152. Doug
  153.  
  154. ------------------------------
  155.  
  156. Date: Sun, 9 Sep 90 23:46:19 EDT
  157. From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
  158. Subject: RSPF problems
  159. To: tcp-group@ucsd.edu
  160.  
  161. We implemented RSPF on our 2 meter TCP/IP network and had very bad
  162. results. IT was implemented as per Anders note. I have to admit that
  163. I have been very busy and have not had a chance to thoroughly read the
  164. RSPF paper. Here is what we are seeing -
  165.  
  166. Jheard (ax heard) list is nothing but garbage.
  167. Hard coded routes (for all interfaces) are lost after
  168. a few hours of operation. This is with 'rspf attach' on just
  169. one interface. After this happens ONLY rspf equiped stations
  170. update the route list. All other routes (net stations and non
  171. rspf NOS) are lost.
  172. Minor note - the reporting router message at trace reverses the
  173. displayed IP address - I.E 44.80.0.70 displays 70.0.80.44
  174.  
  175. We have suspended operation of RSPF to see if there is some other
  176. code problem in the latest G1EMM version.
  177.  
  178. Maybe someone could explain what we should see? Should we see routes
  179. added in the route list? Can hard coded routes still exist and not
  180. be bothered? Should they be route add privates maybe? Should you 
  181. normally not add any routes on the rspf interface and just let it do 
  182. it's work?
  183.  
  184. I think there should be more status info from RSPF. At the moment you
  185. have to trace to see anything. Something like 'rspf status'.
  186.  
  187. Doug
  188.  
  189. ------------------------------
  190.  
  191. Date: Mon, 10 Sep 90 11:24:20 GMT
  192. From: kelvin@kelvin.uk22.bull.com
  193. Subject: rspf status.
  194. To: tcp-group@ucsd.edu
  195.  
  196. Doug et al,
  197.   rspf status is implemented in 900828 v1.1 and I have fixed the reversed
  198. host address on the trace. I have noted all the problems you guys have seen
  199. with routes being lost etc. I haven't seen any ax25 heard list corruption 
  200. however. I'll look into that just in case ax25.h has somehow got changed to
  201. the version with the TX fifo in use. I don't really want to try and debug
  202. too much of rspf as it is really Fred and Anders baby and they are best 
  203. equipped to analyse coding and protocol faults. I'll look at the ARP bug
  204. though.. Thats a bit too serious to leave. I think 90082811.exe/zip are
  205. up on thumper. If not, I'll put the latest I have up A.S.A.P.
  206.      All the best,
  207.                Kelvin.
  208. +-------------------------------------------------+
  209. | Kelvin J.Hill - BULL HN Ltd, Hounslow, England. |
  210. | Internet - kelvin.uk22.bull.com  [128.35.110.6] |
  211. | Amprnet  - g1emm.ampr.org        [44.131.7.6]   |
  212. +-------------------------------------------------+
  213.  
  214. ------------------------------
  215.  
  216. Date: Sun, 9 Sep 90 10:59:57 CDT
  217. From: Jay Maynard <jmaynard@thesis1.hsch.utexas.edu>
  218. Subject: RSPF version doesn't do ARP replies
  219. To: tcp-group@ucsd.edu
  220.  
  221. I built a version of NOS 900828 with Anders Klemets' RSPF and FORTH code
  222. included last night. It seemed to work OK, except that  it wouldn't reply to
  223. an ARP request for its own address. I tried an arp publish, and that didn't
  224. help matters any. Stock 900828 works fine. Any ideas? I hadn't started any
  225. RSPF timers yet, but starting them made no difference. Thanks...
  226.  
  227. ------------------------------
  228.  
  229. End of TCP-Group Digest
  230. ******************************
  231.  
  232. -- 
  233. +------------------------------------------------------------------------------+
  234. |  Peter Franks  |          pete@indep1.mcs.com  OR  pete@indep1.uucp          |
  235. |      NI9D      |                   Use whichever one works                   |
  236. +------------------------------------------------------------------------------+
  237.